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Method for Enhancing the Visibility of Effective Address 
Conipu I: ri I;, ion in PipelAnecl Arc:!? iter: tti res 



The present invention relates to the verification of 
softv:are applications ported betv/een differing instruction set 
architectures and to the debugging of softv/are applications 
executed on pipeline architectures* 

As new general -purpose processors and digital signal 
processors (DSP) arc introduced, existing software applications 
are ported from the old generation of processors to the ne^v 
g.^neration . VJhen an application is ported, the software 

developer responsible for the port must verify that the 
application executes correctly on the new processor- 
architecture. Generally, this verification consists of 
executing the application on the target processor (or in a 
simulator or emulator) a.nd debugging it when problems are 
detected. This can be a time-consuming process if the 
applications, are large. There is no means available to 
automatically verify that the execution of the ported version of 
the application is ecjuivalent to the execution of the original 
version where equivalency means that both versions of the 
application wrote the same values to memory. 

When an appl ication is ported to a new processor 
architecture, there may not be a one-to-one correspondence 
between the memory addresses in the source program and those of 
the target program. The size of the application may have 
increased or decreased due to instriaction set differences or a 
data structure may have been relocated in memory or merged with 
another data structure to take advantage of special features of 
the target architecture. This disparity in memory addresses 
between the source and the target versions of the application 
complicates the verification process as the contents of the 
mapped address registers in each version will not necessarily be 
the same . 

Most modern general -purpose microprocessors and digital 
signal processors have a central processing unit (CPU) pipeline 
v,fhere multiple instructions are in various stages of execution 
at any given time. Instructions may cause effects that mask 
one another at the level of visibility of a debugger, making it 
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^•ifficult for a vGr if icat.ion procor^n or a dobtiggor to see the 



interim rerji.ilts of an instruction in progress. 

An illustrative embodiment of the.presrent invention seeks 
to provide a software system and method for automaticallY 
verifying the correct execution of an application that has been' 
ported from one instruction set architecture (TSA) to another 
ISA, In this method, versions of the application are prepared 
for the source ISA and the target ISA. These versions are then 
ovc'^cuted on a simulator or emulator for the appropriate ISA and 
all changes made in memory during execution are recorded. 
Finally, the results of the two executions are compared to 
dcterir.ine if they are equivalent and the results of this 
verification are displayed. 

In one enibodiment of the present invention, the method is 
enhanced such that during the verification process the source 
and target versions of the application are executed in turn on 
their respective ISA simulator or emulator and a comparison to 
determine equivalency is done each time a change in memory is 
made during execution. 

In euiother embodiment, indirect mem.ory v/rites are validated 
symbolically during the verification process. The verification 
process treats references to address registers as symbols and 
computes the effective addresses of the analogous references in 
the source and target applications independently when attempting 
to verify that two unreconciled states are equivalent. 

In an embodiment, the verification method is further 
enh.=?nced to increase the visibility of effective address 
computation in pipelined architectures. 

Those and other features of the invention will be apparent 
to those skilled in the art from the following detailed 
ce^^cription of the invention, taken together with the 
accompanying drawings in which: 

Figure 1 illustrates the elements of a system embodying the 
prer^jent invention for automatically veri fying the correct 
execution of applications that have been ported from one 
in?: tr\AC t i on set architecture (ISA) to another; 

F.iguv-e 2 is a flow graph of a method used by the system of 
Figure 1 to verify that a source version and a target version of 
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an application ported from one ISA to another oj-ihibit oQuivalent 
exocutiion rcoulco ; 

Figure 3, consisting of Figures 3A-3B, presents a flow 
graph of a version of the method of figure 2 for verbifying by 
co-execution that a source version and a target version of an 
application ported from one ISA to another exhibit equivalent 
results; 

Figures 4A-4H present a simple example of the operation of 
the verification method of Figure 3; 

Figures 5A-5B present the main graphical display of an 
embodiment of the verification method of Figure 3; 

Figures 6A-6F present the options dialog used to specify 
the parameters for controlling a verification pr-ocess .-in an 
embodimont of the verification method of Figure 3; and 

Figure 7 presents a method for enhancing the visibility of 
effective addresses in a pipelined architecture during a 
verification process used by the verification method of Figure 
3 . 

Corresponding numerals and syn^bols in the different figures 
and tables refer to corresponding parts unless otherwise 
indicated. 

A vsri£ic?.tion t^ol has been develODed to facilitate the 

debugqing of ported applications. This tool compares the 

instr\icticn by instruction c>:ocution of the -original or c^ux-cc 
version of the application with the instruction by instruction 
execution of the ported or target version and reports any 
discrepancies at or near the instruction where the two versions 
begin to vary. 

Figure 1 illustrates the elements of a system for 
automatically verifying the correct execution of. applications 
that hv=^ve been ported from one instruction set architecture 
(ISA) to another. General purpose computing system 100 hosts 
two frjoftvj^re development systems as represented by displays 102a 
and 102b and verification software as represented by display 
104 . 

In a first embodiment, softv/are development system 102a 
contains simuleition software to support a source ISA, and 
softv/are development system 102b contains sim\ilation software to 
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support: 



a target ISA, 



The usor prepares two ^/c?r3\or»s of an 



application to be verified, tlie source version and the target 
version. The source version of the application will execute on 
tlie source ISA supported h>y the simulation software in software 
development system 102a and the target version vjill execute on 
the target ISA supported by the simulation software in softwar^e 
development system 1021o. Verification softv/are 104 causes th.e 
two versions of the application be executed in the appropriate 
simulation software and verifies that the application has 
equivalent execution behavior on both ISAs. 

In a second embodiment, emulation hardware 105 and 10 6 
connects source hardware 107 and target hardware 10 8 
respectively to general-purpose computer 100. Emulation 
hardv/are 105 supports the source ISA and emulation hardware 10 6 
supports the target ISA. Emulation hardware 105 is assigned to 
software development system 102a and emulation hardware 106 is 
assigned to software development system 102b. Using the 
appropriate software development system, the user prepares th.e 
source and target versions of an application to be verified. 
The source version is executed on source hardware 107 under the 
control of emulation hardware 105 and the targf^t version is 
executed on target hardware 108 under the control of emulation 
hardware 106. Verification software 104 directs each software 
development system 102 to execute its version of the application 
on the associated emulation hardware, Softv/are development 

system 102 dovmloads the software application to the assigned 
emulation hardv/are and verification softv^are 104 then directs 
the execution of each version of the application and verifies 
that the application has equivalent execution behavior on both 
ISAs. 

In a third embodiment, software development system 102a may 
be connected to emulation hardware 105 supporting one ISA and 
software development system 102b may contain simulation software 
for a different ISA. The user prepares the source and target 
versions of the software application to be verified, one for 
each ISA. Verification software 104 causes the source version 
for the first ISA to be executed by software development system 
102a in em\ilatlon mode and the target version for the second ISA 
to be execured by software development sy.9>tem 102b in simulation 
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mode. Verification software 104 then directs the execution of 
each version of the application and verifies that the 
application has equivalent execution behavior on both TSAs . 

The fact that the application is being executed on a 
simulator or an emulator is irrelevant to the operation of the 
present invention. For purposes of simplicity in the remainder 
of this specification, a simulator V7ill be assumed. However, it 
should be noted that a simulator and an emulator may be used 
interchangeably. For the purposes of the present invention, an 
emulator is: 1) any program, or device with the ability to 
imitate the execution of an instruction set on a processor 
architecture; 2) any device that executes an instruction set as 
it would be executed on its processor architecture (e.g., in- 
circuit emulation); or, 3) any program or device that permits 
user control of the execution of an instruction set on the 
actual processor (on-chip emulation) . 

Figure 2 is a flow graph of a method used by verification 
software 104 to verify that a source version and a target 
version of an application exhibit eqxiivalent execution results. 

In steps 2 02 and 2 04, the source and target versions of the 
application are created. These versions are generally prepared 
(assembled or compiled and linked) using the software 
development tools in the corresponding softv/are development 
system 102, The source code for the source version" is not 

changed. The user merely assembles or compiles the source code 
and creates a load module. The user may make .some changes to 
the source code to create the target version of the application, 
especially if the two ISAs are not instruction set compatible. 
These changes might include accommpdating new instruction 
mnemonics or using features of the target ISA. 

In steps 206 and 208, the source and target versions of 
the application are executed in the corresponding ISA simulators 
under the direction of verification software 104. Verification 
soCtv/are 104 compares the results of the execution of each 
version and determines whether or not the results are 
ecjuivalent. In step 212, verification software 104 displays the 
results of the comparison. 

Figure 3, consisting of Figures 3A-3B, presents a flow 
graph of a version of the method of Figure 2 for verifying by 
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co-execu t i-on t-hat a source versir^n and a target version of an 
application ported from one ISA to another exhibit equivalent 
results. This flow graph illustrates one way in which steps 
206, 208, and 210 of Figure 2 may be interleaved to accomplish 
the verification task. Although this flowgraph illustrates a 
method that begins with the execution of the source version of 
the application, this choice is purely arbitrary. Either 
version may be executed initially. 

In step 3 01, a single instruction of the source version of 
the application is executed in the first ISA simulator. In step 
302, a check is made to determine if the end of the source 
version has been reached. If so, the requested verification is 
complete and execution continues at step 318. At step 318, a 
check is made to determine if any unreconciled state exists. If 
such a state does exist, failure of the verification is 
indicated at step 319 and the method exits. If no unreconciled 
state exists, success is indicated at step 320 and the method 
ends . 

If not, a chock is made at step 3 03 to determine if the 
execution of the instruction has created an unreconciled state. 

An unreconciled state is created by a write to an accumulator, 
an address register, or to memory (direct, indirect, or 
absolute) . Execution of the source version continues until 
either .the- end of the version is reached or an unreconciled 
state is created. When an unreconciled state is found, 

execution of the source version is halted and the target version 
is executed in the second simulator. 

At FJtep 304, a single instruction of the target version of 
the application is executed. If the end of the target version 
is detected in step 3 05, the requested verification is complete 
and the final portion of the method is executed beginning at 
step 318. If an unreconciled state is detected (step 306), this 
state is compared with the unreconciled states detected in the 
execution of the source version at step 307. If it is not 

equivalent to one of the unreconciled states from the previous 
execution of the source version, execution continues at step 3 09 
in subflowgraph 1 of Figure B as indicated at step 3 09a. A 
check is made to determine if the stop on failure option 
(discussed below in reference to FigiJ:re 6C) , is active. If it 
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i not acnive, the current unroconc 11 eel state j.o recorded at 
rrtep 322 and execution continues at step 3 04. If it is, 

failure of the verification is indicated at step 321 and the 
method ends . 

rf an equivalency is found at step 3 07 by comparing ttie 
unreconciled state detected at step 306 with the unreconciled 

\ states found in the execution of the source version, the 

equivalent source and target states are marlced as reconciled. A 
check is made at step 3 08 to determine if all unreconciled 
srafps rpsnltinrj f rnm * the execution of the ^.ource version hav^o 
been reconciled* If not, execution of the target version 
continues at step 304. If all such states have been reconciled, 
a check is made at step 317 to determine if there are any 
unreconciled state that have been detected and recorded during 
Lhis execution of the target version. If there are, execution 
of the source version is resumed at step 310. Otherwise, 
execution of the source version resumes at step 301. 

At step 310, a single instruction of the source version of 
the application is executed. If the end of the source version 
is detected in step 311, the requested verification is complete 
and the final portion of the method is executed beginning at 
rt-f^.p 318. If an unreconciled state is detected (step 312), this 

^ fitate is corr»pared at step 313 with the unreconciled states (if 

any) detected in the execution of the target version.^ If it is 
not equivalent to one of the unreconciled states from the 
previous execution of the target version, execution continues at 
step 3 09 in subf lov/graph 1 of Figure B as indicated at step 
309b. A check is made to determine if the stop on failure 
option (discussed below in reference to Figure 6C) is active. 
If it is not active, the current unreconciled state is recorded 
az step 3 22 and execution continues at step 310. If it is, 

failure of the verification is indicated at step 321 and the 
method ends. 

If an eqiJT valency is found at step 313 by comparing the 
unreconciled state detected at step 312 with the unreconciled 
states found in the execution of the target version, the 

equivalent source and target states are marked as reconciled. A 
choek is made at step 314 to determine if all unreconciled 
scat.es resulting from the execution of the target version have 
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been reconciled. If not, execution of tho source version 
continues at step 310. If all such states have been reconciled, 
a check is made at step 316 to determine if there are any 
unreconciled states that have been detected and recorded during 
this execution of the source version. If there are, execution 
of the target version is resumed at step 304. Otherwise, 
execution of the source version resumes at step 301. 

Figures 4A"4H present a simple example of the operation of 
the verification method of Figure 3. Source column 403 contains 
a short sequence of assembly language instructions for the 
source ISA. Target column 404 contains another short sequence 
of assembly language instructions for the target ISA. This 
latter sequence, when executed, yields equivalent results to 
that of the sequence in source column 403 . The operation of 
each instruction is explained in Table 1. Source state column 
405 and target state column 406 contain any unreconciled state 
that occurs as the associated instruction sequence is executed. 

Arrows 401 and 402 indicate the execution progress of the 
source instruction sequence and the target instruction sequence, 
respectively. Table 2 contains the mapping of the registers 
between the source ISA and the target ISA. This mapping 
determines how each register in the source ISA is to be compared 
to the corresponding register in the target ISA during the 
verification process. 
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Insr.ruct ion 


Explanation 


STM datal, ARB 


Store the address ot datal in 
address register 3 . 


liD #1, K 


Load a register (A) v/ith an 
imittediate value (1) 


NOP 


No operation 


STL A, *AR3-h 


Store the lov7 bits of the 
accumulator (A) to memory at the 
address in address register 3 
and autoincrement the address 


MOV datal, AR3 


Store the address of datal in 
address register 3 


MOV #1, AGO 


Move an immediate value (1) to 
the accumulator (AGO) 


MOV ACO«#0, 
AR3 + 


Move the low bits of the 
accumulator (AGO) to memory at 
the address in address register 
3 and autoincrement the address 



Table 1 



Source 
Register 


Target 
Register 


A 


AGO 


B 


AGl 


ARl 


XARl 


AR2 


XAR2 


AR3 


XAR3 


AR4 


XAR4 


AR5 


XAR5 


AR6 


XAR6 


AR7 


XAR7 



Table 2 



Figure 4A illustrates the initial state before the 
verif icat-i on bogins. Arrows 401 .-^nd . 402 arc pointing to the 
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first instruction in their associated instruction sequences . artd 
state columns 405 and 406 are empty. In Figure 4B, the first 
instruction in source column 403 has been executed and arrow 401 
is now pointing to the second instruction. The execution of tHe 
first instruction caused the address of the variable datal to t>e 
written into register AR3 thus creating an unreconciled state. 
The existence of this unreconciled state is recorded in source 
state column 405. 

Because there is now an unreconciled state, execution of 
the source instruction sequence is stopped and the target 
instruction sequence is executed in an attempt to create an 
equivalent state. In Figure 4C, the first instruction in target 
column 404 has been executed and arrow 402 is pointed to tbe 
subsequent instruction. The execution of the first target 
instruction caused the address of the variable datal to be 
written into register ARB thus creating an unreconciled state. 
The existence of this unreconciled state is recorded in target 
state column 406. Although the value written into ARB by thie 
target sequence is different than that written into ARB by the 
source sequence, these states are possibly equivalent as long as 
ARB is used as an address register. However, the states are not 
yet reconciled. Both instruction sequences must be executed 
fiirther to ascertain whether a reconciliation occurs. 

Leaving the .cont«=;n t:;=i of ^itaLe col laiinifii 405 c^iid 40G ujLxvlActiis-j*=:d 
nfs a full RQui val enr:y ha.s not bepn founds fhie exprutinn nf the 

.'-.wii r V ;t-t Ml^si.^ul:l icjii fst^i^! it-^nt :in r ?s r f-.'sniiit-»il . Tii Fitjure* 4r/, i. lie 

r^pcnnd i n.-st met i on nf the sorirrp .spqnenre has ber^n expruted and 
arrow 401 ia pointing to the oufcaGquent NOD inatirue tioa . TKs 
execution of this instruction has created another unreconciled 
scate as indicated in source state column 405 because a constant 
1 beeii wrlLLen to the cicjcuiuulaLur A. 

RetUT-ning to the target instruct iv':^n sequence ^ the next 
instruction in its sequence is executed as shovm in Figure 4E . 
Arrow 4 02 Pias been moved to the subsequent NOP instruction and a 
corstant 1 has been written to accumulator ACO . This new 

L*i'Aj- t^C^OiAv, il'crvJl ;=>LciL^r: ^:=> a.d^.iw>xdcd in Lcti.yt=;L i^LciLt:; <^wlu.iiui 40G- Afc> 

Table 2 above indicQtao, QRCj\amulat".r/ir A in f.hr* fifsurrif*. TP^A h^-/ 
be compared to accumulator ACO in the target architecture for 
verification purposes. Both have had the same value written to 
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them, so the cource state and tine target state are equivalent 
and may be reconciled. These states may now be removed from 
state columns 405 and 406 as is shov/n in Figure 4F. 

Returning to the source instruction seQuence, tbe 
instructions are executed until a new unreconciled state is 
created by the execution of the STL instruction. As Figure 4F 
illustrates, arrow 401 is now pointing to the NOP instruction 
following the STL instruction. This instruction has caused the 
contents of accumulator A to be written to the memory address in 
register AR3 . ' This new unreconciled state is reflected in state 
column 4 03 ♦ 

Returning to the target instruction secfuence, the 
instructions are executed until a nev/ unreconciled state is 
created by the execution of the MOV instruction. As Figure 4G 
illustrates, arrow 403 is now pointing to the NOP instruction 
follov/ing the final MOV instruction in the target instruction 
sequence. This last MOV instruction has caused the contents of 
accumulator AGO to be written to the memory address in register 
AR3. This new unreconciled state is reflected in state column 
405. 

At this point, both the source and the target have- used 
corresponding registers (see Table 2) as address registers and 
have v/ritten the same value to memory based on the contents of 
those registers. The execution states of the source arid the 
L':\rget ax'e equivalent and the unreconciled states dealing with 
AR3 may now bo removed from state columns 405 and 406, Figure 
reflects that the verification up to this point is successful 
and all unreconciled states have been reconciled. 

Figures 5A-5B representative illustrations of a main 
graphical di'i^play of an embodiment of the present invention. 
Figure 5A exemplifies the contents of this display when the 
verification program is started and Figure 5B exemplifies the 
contents of this display when a verification is in progress. 
This display is comprised of menu bar 500, tool bar 502, message 
view 504, verification state view 506, and status bar 508. Menu 
bar 50C is used by the user to input all commands to the 
verification tool. The options available for each menu item are 
presented in Table 3 below. 
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i^ction 


^'ile t 


slev7 (Ctrl -IN} 

c 


-losing- the current document if 
Dne exists. 


c 


Dpen(ctrl-O) ( 


^pen an existing verification 




^ave (ctrl-S) . 

< 


5ave the current verification 
document 




Save As 


Save the current verification 
document as a drrcerent. naine 




21ose 

• 


Close the current verification 
document. Prompt the user 
otterxng no save ir une ooouiuerii- 
n?^cj ViP^^^Ti modified. 




<1ZX L^J- - - 

f i 1©4> 


TT-r* t-rk 4 nf^ the most recentlv 
opened files. Selecting one of^ 
these will open that file. 


Exi t 


Exit the program ^ 




Toolbciir 


Show/hide the toolbar 


Stacus bar 


Show/hide the status bar j 


Code Composer 


Show/hide software development 


Options - . . 


Show the options dialog 




Run 

Veri f ication 


Run a verification session until a 
problem is found or the stop 


Step 

Verif icat ion 


Step one software development 
vwnicnever n*red&> uo j^fc: t> uti^jb^t^^^^v 
until the state of the 
verification changes 


Ver i f ication 


Stop a verification that is 
running 


Step Source 


Step the program in the source 
software development system one 
instruct Ion 
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Step Target 


Step Che program in the target' 
software develonmerit fivs=-tc»-m n-nri 
■i n.strnrt 1 on ; 


Help 


Topics 


Bring up help, showing the tablei 
of contents 


About 


Show the About dialog- 



Table 3 



Toolbar 502 provides the user v/itb icons to use as 
shortcuts to commonly used functions such as those used to 
control the progress of the verification. Status bar 508 

displays messages indicating the state of the verification 
process. As the source or target program is stepped, the action 
taken is displayed on the right side of status bar 508. Also, a 
short description of each menu item or toolbar , button 
highlighted appears in status bar 508. 

Verification state view 506 displays the list of 'all 
unreconciled state changes that have occurred in the source and 
target programs. It displays the register or memory address 
that is affected and the contents of that register or; memory 
address. Icons in column 510 indicate the status of the 

reconciliation attempts for each associated pair of unreconciled 
states. Table 4 defines the icons that may be present in" column 
510. An example of the contents of verification state view 50 6 
during the execution of a verification is shown in figure 5B . 
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Tcon : 


Elxplanation 


] 


NTo icon indicates that this item has not yet 
3<^en oe ue iTrfiinGci co iitcii-c-ij xit-?L. iiu:ii^^^ii. 


■ 

Check 


?i green check indicates that this item has 
matched and will be cleared from the display 
after a number of steps indicated in the 
Display dialog. 


X 


A red X indicates that this item has boen 
written by both the source and the target, 
but with different values. This indicates 
an incompatibility that should be examined 
by the user. 




A purple exclamation indicates that a 
warning has been noted on this item because 
the state of the two CPUs was not consistent 
during the execution of this item. This 
item should be examined by the user. 


Clock 


A clock indicates that this item is over 
aged, that is, significant time has elapsed 
(time limit specified by user) since one 
version wrote to this item and the other 
version has yet to write to tne item. ine 
verification process will continue to track 
the item looking for a m.atch, but this item 
will no longer influence e:>cecution of the 
verification algorithm. 



Table 4 

Message view 504 displays a scrollable list of messages 
from the verification program. These messages keep the user 
informed of the state of the verification process. The user may 
control what level of messages are sent to this window 
(diagnostics, verbose information, short information, error 
niessages) through the options dicilog described in the discussion 
of Figures 6A-6F below and may -log the messages to a file. 
Messages may be triggered by starting, stopping, or stepping a 
verification. the detection. ^,fof a stop address in the source 
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program, the removal of an address regi.*:?ter miomatc'h due to a. 
successful write-through of the address register with the same 



during the execution of a verification is shown in figure 5B . 

Figures 6A-6F are representative of an options dialog used 
to specify the parameters for controlling a verification. Each, 
of 6A-6F represents a screen displayed in response to the 
selection of one of the tabs 630-635. When the user selects 
File/New (see Table 3) from toolbar 500, the options dialog 
screen in figure 6A is displayed. {This dialog is also 

displayed when the user selects the View/Options from toolbar 
500 to modify a previously created verification document or when 
file tab 630 is selected,) Files display 600, which is the 
default initial screen when the options dialog is displayed, 
allows the user to specify the source and target programs to be 
loaded into the source and target simulators . 

A verification document is a file that contains all the 
parameters for a verification session. These parameters are 
defined by the user using the options dialog shown in Figure 6A. 

The parameters are comprised of the file names of the source 
and target versions of the application, a list of ON, OFF, and 
STOP trigger addresses for both the source and target versions, 
the ma>:imum number of verification steps to be executed before 
an unmatched item is considered a difference, etc, 

Triggers display 602, displayed by selection trigger tab 
631 and shown in Figiare 6B, allows the user to specify addresses 
in the source and target programs v,?here verification is turned 
en, turned off, or stopped. ON verification points are 

addresses where the validation process should start (or restart) 
reconciling the actions of the source and target programs. OFF 
veri f i cah ion points are addresses where the verification should 
stop reconciliation and simply run the program until the next ON 
or STOP point. STOP verification points are places where the 
verification process should halt. Addresses 604 and 606 may be 
entered in decimal or hexadecimal numeric format or may be an 
actual symbol in the program. List displays 608 and 610 display 
the addresses and types of all triggers that have been specified 
for the source and target programs, respectively. 



values, etc. 



An example of the contents of message view 504 
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Verification di5:?play 612, displayed by Gclccting 
verification tab 632 and shown in Figure 6C, allows the user to 
set some generic options related to the verification process . 
These options include stop options 614 and verification type 
options 616 . Stop options 614 allows the user to optionally 

require the verification process to halt when a difference 
between the source and target programs is detected. The meaning 
of a difference" depends on the selection made in address 
registers options 619 (see Figure 6D) . If this option is not 
selected, the verification process will execute and simply log 
differences to message view 504 and optionally to a message log 
file. Verification type options 616 allow the user to specify 
the ISAs of the source and target programs. 

Registers display 618, displayed by selecting registers tab 
633 and shown in Figure 6D, allows the user to specify the 
strictness of the register comparison to be used during the 
verification process. If the "Track register contents" of 
Address Registers 619 is selected, the contents of the address 
registers in the source program are compared with the contents 
of their counterparts in the target program. (See Table 2.) 
This option should only be used if the two programs have been 
linked at the same memory location. It will provide a stricter 
comparison between the two programs. If the two programs have 
not been, linked at the same memory location, the "Do not track,.*" 
option of Address Registers 619 should be used. With this 
option, the actual contents of the address registers will not be 
tracked but writes to memory through those registers will be 
tracked. 

Display display 620, displayed by selecting display tab 634 
and shown in Figure 6E, allows the user to specify the level of 
detail to be shown in verification state view 506 and message 
view 504. In State Display 622, the user may specify the number 
of steps to show matched (reconciled) items before removing them 
from verification state view 506. In Messages 624, the user may 
specify the types of messages to be displayed in message view 
504 and request to have the messages written to a user-specified 
log file. The message types are defined in Table 5. 
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Errors 


A recoverable error due to an 
unexpected input to the verification 
tool. The tool attempts to continue 
the verification, but the user should 
examine the source of the error. 
This type of error may occur if the 
simulator detects invalid 
instructions . 


Warnings 


The verification process has found an 
inconsistency in the execution the 
source and target programs . The 
exact nature of the inconsistency is 
listed in verification state view 
506. 


Information 


Informational messages for the user 
about the status of the verification 
(e.g. ON, OFF, STOP triggers hit) , 
Running, Stopped, Stepped. 


Ver-bose 
Information 


More detailed information, 
particularly suited for logging to 
the log file. The text from Comments 
display 624 is printed as a verbose 
message when the session is started. 


Diagnostics 

1 


Diagnostic messages meant to aid in 

the reporting of bugs in the 

verification tool. This level of 

messages may produce a great deal of 

text, including the details of each 

step of the verification process. 
— ■— .— , _ 



Table 5 

Comments display 62 6, displayed by selecting comments tab 
63 5 and shown in Figure 6F, allows the user to enter a text 
comment for the associated verification document. This is 
useful for describing the purpose of the document. These 
comments are displayed in message view 504 when the document is 
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op'?ned iC the verbose information option is select cd in Messages 
624. 

When an application is ported to a differ-ent ISA, there may 
not be a one-to-one cor-re.^pondence between the memory addresses j 
in the source program and those of the target program. The size 
of the application may have increased or decreased due to ISA 
differences or a data structure may have been relocated in 
nnemory or merged with another data structure to take advantage 
of special features in the target IGA, This disparity in memory 
addresses between the source and the target versions of the 
application complicates the verification process as the contents 
of the mapped address registers in each, version will not j 
necessarily be the same. 

Indirect memory writes are validated symbolically during 
the verification process. Indirect writes to memory tbrough 
address register expressions are verified by determining that 
the values written to memory locations computed by the address 
register expressions in the source and target versions are 
equivalent. The verification process treats references to 

address registers symbolically and computes the effective 
addre.^ses of the analogous references in the source and target 
applications independently when attempting to verify that two 
imreconr i 1 ed stc?<tes are equivalent. 

The example sequence of assembly language C9de in Figures 
4A-4H illustrates this embodiment. The memory location of datal 
is different in the source and target code, so that the contents ^ 
of ARB after the first instruction in each code sequence is j 
different as sho^Am in source state 405 and target state 406 in 
Figure 4C. When the instruction STL A, *AR3+ is executed, the j 
contents of register A are written to the memory address stored 
in register ARB as shown in source state 405 of Figure 4F. At 
this point, rather than treating the unreconciled state created 
by this change to memory as a write to the memory address 0x800, 
the Mprr-f-onc i 1 Gd state is remembered as being a v/rite to the 
r.:c-mory address represented by the symbol *AR3 . Note that if the 1 
ur recorc L:i o*d state is viewed as being a change in memory at i 
address 0x800, no eqvxivalent state v/ould ever be detected on the 1 
tar-get processor because of the different memory addresses of 1 
the symbol datal. When the instruction MOV ACO«#0, AR3+ is J 
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f'-roouted on the target IFjA, the contents of register AGO is 
v/ritton to ttie menaory address stored in register AP3 as shown in 



viewed afs being a write to the meraory address represented by the 



state is equivalent to the unreconciled state created during the 
execution of the code sequence on the source ISA, the validation 
process recognizes that the source lanreconciled state and the 
target unreconciled state are both v;rites to the same symbol. 
(The registers AR3 and XAR3 are equivalent for verification 
purposes as shovm in Table 2,) Therefore, if the same value 

has been written to memoiry at the respective addresses 
r^prosnnted by this symbol in the source and target executions, 
the tv/o unreconciled states are equivalent and may be 
reconciled. It is important to note that any register 

G:<pre3sion involving symbols and constants, such as XAR3 + 5, 
not just simple register expressions, will be handled similarly. 

Figure 7 presents a method for enhancing the visibility of 
effective addresses in a pipelined architecture duif-ing a 
verification process. Note: An effective address is the address 
at which a memory operation occurred. Through the use of this 
method, a verification process or debugger can infer the 
effective address of many instructions in a pipeline 
architecture v/here that effective address v/ould otherwise be 
invisible due to the behavior of the pipeline. 

Most modern general -purpose microprocessors and digital 
r^irjral procesi^ors have a central processirg unit (CPU) pipeline 
-.vhere mu?xtiple instructions are in various stages of execution 
at any given time. Instructions move through the pipeline like 
products through an assembly line. At each phase of the 
pipeline, each instruction performs an action specific to that 
phase. For er^ample, an ADD instruction will read both operands 
during the Read phase and perform the addition during a later 
Execute phase. 

When a pipelined processor is halted, often the pipeline is 
left "full'* of partially executed instructions. The state of 
execution of the application includes whatever effects have 
c-ilready La\ken place from these partially executed instructions. 
ln<r true t ions may cause effects that mask one another, making it 



target state 406 of Figure 4G. 



This unreconciled state is 



symbol '^XARS . 



l\Then checking to see if this new unreconciled 
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c^: f f iculn to see the interim re.'-;iilt-3 of an innhruction in 
progress. One particu?.ar problem is determining the effective 
c-ddre^s of a memory operation v/hen that address is calculated, 
used, and altered while the instruction caur^ing the memor^y 
operation is still in the pipeline. By the time such an 
instruction is completely executed, the effective address of the 
actual memory operation is no longer available. 

For example, assume that the CPU instruction pipeline has 
four phases; decode, access, read, and execute. Instructions 
enter the pipeline in the decode phase and move through the 
access, read, and execute phases in sequence. Table 6 

illustrates what occurs in each phase of the pipeline when a 
simple memory write is caused by the execution of a store 
instruction such as ST A, *ARl-h . This instruction causes the 
contents of register A to be written into memory at the 
effective address contained in register ARl , In addition, ARl 
v/ill be incremented to the next memory address. 



Pipeline 


Effect 


Phase 




Execute 


Memory at the effective address is 
written 


Read 


Value of A is read 


Access. 


Effective address, for this, operation 
is set, and ARl is incremented 


Decode 


Instruction is decoded (i.e. 
recognized) 



Table 6 

As Table 6 illustrates, by the time the instruction is executed, 
the register ARl no longer contains the address where the actual 
v^rite occurred, the effective address of the instruction. This 
effective address is almost, never available to emulators or 
debuggers and discerning the actual effective address is 
difficult at times. 

The method presented in Figure 7 works within the following 
ronntraints winch are common to most pipelined architectures: 1) 
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3 LI insbruchions enter the pipclim^ at one p.?..vt iciilar phase 
(often called decode) ; 2) all in.'.;?:ructions travel through the 
eritire pipeline even though they may not perforin meaningful work 
at each phase of the pipeline; and, 3) the number of clock 
cycles that a given instruction will spend in each phase of th.e 
pipeline can be determined a priori. 

At step 700, a determination is made as to what 
instructions are currently in the pipeline. There are a number^ 
of ways to accomplish this determination including: 1) 
executing the software in single-step mode and recording each 
instruction as it enters the pipeline; or, 2) utilizing an 
emulator or simulator that can report which instruction is in 
each phase of the pipeline. Such features are available in some 
modern emulators and simulators . 

Once this determination is made, the current effective 
address for any relevant instruction in the pipeline is 
ascertainable in most instances. Note: In rare cases, it may 
not be possible to determine the current effective address such 
as when an address register is used and then reloaded from 
laemory in a subsequent instruction. First, in step 702, the 
effective address delay of the instrucrtion .is calculated. This 
effective address delay is the number of CPU clock cycles from 
the point v/here the instruction enters the pipeline at the 
decode phase to the point where the effective address that will 
be used for the instruction is fully computed. The effective 
address delay is then reduced by the number of clock cycles that 
have occurred since the instruction entered the pipeline. The 
res:ulting raimber is used in subsequent steps of the method to 
dotrermine if a current effective address is available, is not 
applicable as the in.struction has not reached a phase where the 
effective address is calculated, or must be "inferred" because 
the effective address has been masked by the execution of 
sub*?oquent instructions in the pipeline. 

In step 704, if the current effective address delay of the 
inr:?truct ion is 0, the effective address for the memory operation 
is available and is reported at step 718. The method then 
proceeds to the next instruction in the pipeline, if any, via 
step 720. If the current effective address delay is found not 
to be less than 0 at s't^p 706, no .further action for the 
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instruction under consideration is required as the instruction 
has not yet reached a point where a memory operation has 
occurred. The method proceeds to the next instruction in the 
pipeline, if any, via step 720. 

If, at step 7 06, the current effective address delay is 
negative, the effective address of the memory operation has 
potentially been compromised. At step 70 8, a check is made to 
determine if any of the subsequent instructions in the pipeline 
have modified any of the factors that are involved in the 
effective address calculation of the instruction under 
consideration. If not, the current effective address may be 
reported and the method proceeds to the next instruction in the 
pipeline, if any, via step 720. If the subsequent instructions 
have modified one or more of the factors involved in the 
effective address calculation, a check is made at step 710 to 
determine if these modifications are reversible (i.e., the 
modifications can be applied in reverse order to the current 
effective address to determine the actual effective address of 
the instruction) . If the modifications are reversible, at step 
712, the actual effective address is determined and reported. 
The method proceeds to the next instruction in the pipeline, if 
any, at step 720. If, at step 710, a determination is made that 
the modifications are not reversible, an indication that there 
is no^ effective address available for the . current . instruction is 
reported and the method proceeds to the next instruction in the i 
pipeline, if any, at step 720. 

The verification process includes a method for enhancing j 
the visibility of effective address computation in pipelined 
architectures when the application to be verified is executed on a 
a CPU with a pipelined architecture (source and/or target) . The 
application program is executed in single- step mode to detect 
unreconciled states as they occur. At each execution step, the ' 
verification process calculates the current effective address 
delay for each instruction in the pipeline and reports the 
current effective address (if possible) as illustrated in Figure 
7. The verification process knows V7hat instructions are in the I 
pipeline and their current pipeline phase because it remembers I 
each instruction as it enters the pipeline and knows how many I 
clock cycles are required, for e'ach 'relevant phase of each ■ 
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.nr;lr. ruction . 

For example, consider the execution of the code sequence in 
?:ible 7. 



(line 


1) 


NOP 








(line 








2) 




( line 


3) 


STM 


#100, 


ARI 


ARI 


(line 


4) 


ST 


A, 


*AR1 + 


memory (10 0) 


( line 


5) 


ST 


A, 


*AR1 + 


; memory (101) = 


( line 


6) 


NOP 








( 1 ine 








7) 





NOP 
100 ; 

=: A 
A 

NOP 



Table 7 



Table 8 contains a brief explanation of the operation of eacb 
instruction of the code sequence in Table 7. 



Ins truction 


Explanation 


NOP 


No operation 


STM • #100, 
ARi 


Store immediate value (100) into 
address register 1 


ST A, *AR1+ 


Store the contents of recjister A 
into the memory address contained 
in address register 1 and 
auto increment the address 



Table 8 
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T'-Me 9 shov7 the contents of the pipeline when the instruction 
on line 4 of Tcible 7 enters the decode phase. 



JL — L. -i- -1- I.X vCZ 

Phase 




Execute 


(line 2) NOP 


Read 


(line 3) STM #100, 
ARl 


Access 


(empty) 


Decode 


(line 4) ST A, 
*AR1 + 



Table 9 

The effective address delay for this instruction is two because 
its effective address will be set in two clock cycles. The 
pipeline contents after the next single step are shown in Table 
10 . 



Pipeline 


Instruction 




Phase 






Execute 


(line 3) STM #100, 
ARl 




Read 


' (empty) • : - ^ 




Access 


(line 4) ST A, 
*AR1 + 




Decode 


(line 5) ST A, 
*AR1 + 





T'3b1 e 10 ♦ . 

7-- this point, the effect address delay of the instruction on 
line 4 is one because its effective siddress will be set in one 
ryrlR. The d.nstruc tion on line 5 is a tV70-cycle instruction so^ 
on tbe next single step, the pipeline will advance two phases. 
The result inc? contents of the pipeline are shoivn in Table 11. 
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Pipeline 
Phase 


Instruction 


Execute 


(line 4) ST A, 
*AR1+ 


Read 


(line 5) ST A, 
*AR1 + 


Access 


( empty) 


Decode 


(line 6) NOP 



Table 11 

The effective address delay for the instruction on line 4 is now 
a negative one because of the two-cycle instruction that 
follov/ed it in the pipeline. The addr-ess in ART has been 
incremented twice and the effective address of the instruction 
is not visible to the verification process. Because the 

instruction on line 5 has not changed the contents of ARl {other 
than the auto increment) , the effective address for the 
instruction on line 4 can be "reverse-engineered" by' simple 
subtraction. In the general case, this reverse engineering ' may 
be more difficult if bit-reversed addressing or circular 
addressing modes are used but is it usually a tractable problem. 

In the rare case where it is not possible to reverse the. effect 
of a later instruction, such as reloading" ARl from memory rather 
than a simple au toincrement , the verification process warns the 
user that the verification might be inaccurate. 

Thus, a system and methods have been described for 
verifying that a ported version of a software application has 
e>recution behavior eQuivalent to the original version. The 
present invention provides a significant advantage over the 
prior art. Verification by comparing the execution behavior of 
the source and target versions of an application provides 
thorough and detailed validation that the target version is 
executing correctly. Because the verification process examines 
each instruction, the user can know exactly v/here the two 
ver^r-ions of the application differ, not just that they differ. 
And, by running each version of the application in a simulator 
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cr emulator under the control of a full software developmerLt 
system, v/hen a discrepancy is found chir incj the verification 
process, the debugger in each .software development system can t>e 
activated at the point of the discrepancy, thus facilitating the 
delDug process. 

The present invention is discussed in conjunction with 
softv/are verification and debugging • However, it ha.s 

applications that extend beyond softv/are. While the invention 
has been described V7ith reference to illustrative embodiments, 
this description should not be construed in a limiting sense. 
Various other embodiments of the invention will be apparent to 
persons skilled in the art upon reference to this description. 

For example, the verification method may be applied to any 
automated process that produces intermediate states during 
exiecution and is amenable to emulation or simulation. 

As used herein, the term ^^debug'' is not intended to be 
limiting. Debug operations refer to any of the sort of tasks 
performed during development of softv/are and/or hardware, 
including hardware emulation. 
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What is Claimed is: 

1» A method for determining in software the effective 
address of instructions in a program executed on a pipelined 
architecture where there is no external visibility into the 
pipeline/ the method comprising: 

executing a first program; 

determining that a first instruction is in the pipelined- 
calculating the current effective address delay of the 
instruction in the pipeline; 

finding that a valid effective address for the instruction is 

instruction; 

computing the effective address of the instruction if a valid 
effective address is not avan 1 ab3.f^;. and 

reporting the effective address of the instruction. 

2. The method of Claim 1 wherein: 
the step of calculating comprises subtracting the number of 
clock cycles that have occurred since the instruction entered the 
pipeline from the number of clock cycles required to compute the 
effective address of the instruction; 

the step of finding comprises determining that the . current 
effective address delay is 0; and 

the step of computing is executed if the current effective 
address delay is less than 0. 
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Met:hod for Enht^incing the Vi.^ ibi I i of Fffeci:ive Address 
• Computation in Pipelined Architectures 



Abstract 



Tho invention relates to a iriothod to increase th.e 
visibility of effective address computation in pipelined 
architectures. In this method, the current effective address 
delciy of each instruction in the pipeline is calculated (702) • 

The current effective address delay is used to determine if a 
valid effective address is available for each instruction (705, 
706) . If a valid effective address for an instruction is not 
available (706), it is computed if possible (710, 712). 



Figure 7 
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STM 

clataK 

AR3 


10?., 




MOV <!atal, AR3 


empty 




LD #1, A 


empty 




MOV #1. ACO 




NOP 




NOP 




NOP 


• 


NOP 




STL A, 
*AR3+ 




MOVAC0«#0. 
AR3+ 




NOP 




^OP 


40:^ 405 404 406 


Source 
execution 


Source 


Source 
state 


Target 
execution 


Target 


'I'argct 
state 




STM 

data I , 
AR3 


402. 

AR3 = 
0x800 




MOV data 1,AR3 


empty 




LD#I. A 




MOV#l, ACO 




NOP 




NOP 






NOP 




NOP 




STL A, 
"'AR3+ 




MOV ACO«#0, 
AR3+ 




NOP 




NOP 


403 405 404 406 


Source 
cxiMriitlou 


Source 


Source 
.state 


Tai^et 
execution 


Target 


Target 
state 




STM 

danil, 

AR3 


402 

AR3 = 
0x800 




MOV data I.AR3 


XAR3 = 
0x430 




LD#1. A 




MOV #L ACO 




NOP 




NOP 




NOP 




NOP 




S TL A, 

•*AR3f 




MOV ACO«#0, 
AR3+ 




NOP 






NOP 



Figure 4 A 
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AR3 
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NOP 




NOP 
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AR3+ 




NOP 


|NOP 
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execution 


Source 
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execution 


Target 
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state 
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datal, 

AR3 


AR3 = 
0x800 

A=,r 




MOV datal, AR3 


XAR3 = 
0x430 
AC0= 1 




LD#I, A 




MOV # 1 , ACO 




NOP 


TTii]."- ^ 


NOP 




NOP 




NOP 




STL A, 

*AR3f 




MOV ACO«//0, 
AR3+ 




NOP 






NOP 
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state 


Target 
execution 
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STM 
data 1 , 
AR3 


AR3 = 
Ox SCO 
l*AR3)J 
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MOV daial, AR3 




I.D#1, A 




MOV#L ACO 




NOP 




NOP 




NOP 




NOP 




STL A, 

=^\R3+ 




MOV AC(}«#0, 
AR3+ 


II ■iiiiiii^i^t 


NOP 




NOP 
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Target 
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